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SUMMARY 


)  This  thesis  documents  the  design  and  implementation 
of  an  operating  system  for  the  Georgia  Institute  of 
Technology  Information  aruT 'Compel ter  Science  Laboratory 
(GIT/ICSL).  The  operating  system"*,  designated  PCOS,  was 
developed  in  order  to  provide  a  pedagogical  aid  which  could 
be  used  to  provide  students  with  a  better  understanding  of 

(  I  t  •  >  I  '  I  ^  ;  V  r 

operating  system  principles.  PCOS  is  inten&ed  td'  be  A 
simple  yet  functional  operating  system  which  students  can 
analyze,  modify,  and  extend. 

/ 

PCOS  is  an  acronym  wjrich  stands  for  Personal 
Computer  Operating  System.  ->PCOS  was  designed  and 
implemented  on  an  IBM  Personal  Computer  (IBM  PC)"^  However, 
the  strategy  used  to  structure  PCOS  along  with  the 
algorithms  used  to  implement  PCOS  are  applicable  to  most 


contemporary  computer  systems. 

This  thesis  presents  the  requirements  and  design 
criteria  which  were  used  to  guide  the  design  of  PCOS.  The 
decisions  made  during  the  design  of  PCOS  are  discussed. 

The  algorithms  and  data  structures  used  to  implement  PCOS 
are  discussed.  And,  further  development  of  PCOS  is  also 
discussed . 
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CHAPTER  I 

INTRODUCTION 

«  Basically,  an  operating  system  is  a  resource 

manager.  It  is  responsible  for  the  effective  and  efficient 
management  of  computer  hardware.  Consequently,  the 
operating  system  is  one  of  the  key  components  of  a  computer 
system . 

The  study  of  operating  systems  is  an  integral  part 
of  any  progressive  computer  science  curriculum. 

Introductory  courses  present  the  general  principles  of 
operating  systems  while  advanced  courses  present  operating 
system  design  strategies  and  implementation  techniques  in 
greater  detail. 

Courses  on  operating  systems  should  provide  insight 
into  the  design  and  implementation  of  operating  systems. 
However,  Lions  (1978)  points  out  that  the  presentation  of 
general  principles  alone  proves  to  be  "rather  dry 
intellectual  fodder  for  students  with  limited  practical 
experience." 

In  an  effort  to  provide  students  with  a  better 
understanding  of  the  design  and  implementation  of  operating 
systems,  educators  such  as  Lions  have  proposed  several 
different  approaches  for  teaching  operating  system 
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principles.  Since  students  are  usually  more  interested  in 
seeing  something  work  than  reading  theoretical  examples, 
the  approaches  emphasize  the  study  and  development  of 
actual  operating  systems.  One  approach  is  to  conduct  a 
comprehensive  stud. y  of  an  actual  operating  system  in  an 
effort  to  show  students  how  theory  has  been  put  into  action 
(Lions,  1978;  McCharen,  1980).  Another  approach  is  to 
modify  or  extend  an  existing  operating  system  (Bauer, 

1975).  Yet  another  approach  is  to  require  students  to 
develop  a  pedagogical  operating  system  from  scratch 
(LaGarde,  Olivier  &  Padiou,  1981;  Lane,  1981;  Wadland 
1980)  . 

This  thesis  documents  the  design  and  implementation 
of  PCOS ,  an  operating  system  for  the  Georgia  Institute  of 
Technology  Information  and  Computer  Science  Laboratory 
(GIT/ICSL).  The  purpose  of  this  research  project  is  to 
initiate  development  of  an  operating  system  for  the  IBM 
Personal  Computer  which  can  be  used  to  provide  students 
with  a  better  understanding  of  operating  system  principles. 
PCOS  is  intended  to  be  a  simple  yet  functional  operating 
system  which  students  can  analyze,  modify,  and  extend. 

PCOS  is  an  acronym  which  stands  for  Personal  Computer 
Operating  System. 

The  ne.’C  chapter  discusses  the  design  and  the 
implementation  of  PCOS  in  detail.  Chapter  Three  discusses 
further  development  of  PCOS.  And,  Chapter  Four  presents 


CHAPTER  II 


THE  PCOS  PROJECT 

Requirements 

As  stated  in  the  previous  chapter,  the  purpose  of 
this  research  project  is  to  develop  an  operating  system 
which  can  be  used  to  provide  students  with  a  better 
understanding  of  operating  system  principles.  The  general 
requirement  is  that  it  be  a  good  example  of  current 
operating  system  design  practice. 

The  specific  requirements  for  PCOS  were  established 
after  reviewing  the  capabilities  of  several  commercially 
available  operating  systems  (Banahan  &  Rutter,  1983; 

Deitel,  1983;  Holt,  1983;  Madnick  &  Donovan,  1974;  McKeag, 
1976;  Zarrella,  1981,  1982).  It  was  decided  that  PCOS 
should  offer  the  following  capabilities: 

(1)  provide  a  single-user  environment, 

(2)  support  multiprogramming,  and 

(3)  support  sequential  disk  file  organization. 

Design 

Criteria 

Before  discussing  the  design  decisions,  it  is 
necessary  to  discuss  the  general  design  criteria  used  to 
guide  this  development  effort.  The  general  design  criteria 


are  as  follows:  simplicity,  efficiency,  and 
maintainability  . 

PCOS  is  intended  to  be  used  to  provide  students  with 
a  better  understanding  of  operating  system  principles. 
Without  simplicity  a  complete  understanding  of  the  system 
would  not  be  possible.  Therefore,  PCOS  should  not  contain 
any  unnecessary  complexity.  It  should  be  based  on  a  small 
set  of  relatively  simple  concepts. 

PCOS  is  also  intended  to  be  a  simple  yet  functional 
operating  system.  In  order  to  be  truely  functional  it  must 
be  efficient. 

To  be  able  to  adapt  to  a  constantly  changing 
environment,  PCOS  should  be  easy  to  maintain.  As  a  result, 
PCOS  should  be  well  structured. 

Decisions 

This  section  discusses  the  major  design  decisions 
made  during  the  development  of  PCOS.  The  rational  behind 
each  decision  is  presented. 

First,  a  computer  system  was  selected  for  the 
initial  implementation  of  PCOS.  The  Information  and 
Computer  Science  Laboratory  at  Georgia  Tech  has  several 
computer  systems  which  are  available  on  a  regular  basis  for 
student  research.  However,  most  of  the  systems  are  multi¬ 
user  systems.  Since  it  would  be  to  costly  in  terms  of  lost 
service  alone  to  dedicate  a  multi-user  system  to  a  single 
user,  they  were  eliminated  from  further  consideration.  In 
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addition  to  the  multi-user  systems,  there  are  several 
single-user  systems.  Of  the  single-user  systems,  the  IBM 
PC  seemed  to  be  the  most  promising.  A  typical  IBM  PC 
configuration  includes  a  CPU,  a  keyboard,  a  monitor,  128k 
bytes  of  internal  memory,  2  5-1/4"  floppy  disk  drives,  and 
a  dot-matrix  printer.  In  addition,  the  Intel  8088 
microprocessor  used  in  the  IBM  PC  supports  both  segmented 
memory  and  interrupts.  Given  the  above  considerations,  the 
IBM  PC  was  selected. 

Once  the  implementation  system  was  selected,  the 
implementation  language  was  chosen.  The  choice  of  an 
implementation  language  was  easy.  At  the  time,  only  a  few 
languages  were  available:  Pascal,  Fortran,  Basic,  and 
assembly  language.  Operating  systems  are  often  implemented 
in  assembly  language  for  space  and  time  considerations 
(Freedman,  1977).  However,  since  it  is  easier  to  develop 
and  maintain  a  program  written  in  a  high-order  language 
(HOL),  Pascal  was  chosen  to  be  the  primary  design  and 
implementation  language  of  PCOS .  In  order  to  enhance 
both  maintainability  and  portability,  assembly  language  was 
used  to  code  only  those  routines  which  were  neither 
feasible  nor  practical  to  implement  using  Pascal. 

Next  the  strategy  used  to  structure  the  PCOS  was 
choosen.  Both  the  monolithic  monitor  approach  and  the 
kernel  approach  are  strategies  which  can  be  used  to 
structure  operating  systems  (Deitel,  1983;  Holt,  1983). 
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The  monolithic  monitor  approach  collects  the 
resource  management  functions  provided  by  an  operating 
system  into  a  single,  monolithic  module.  The  main 
advantage  of  the  monolithic  monitor  approach  is  its 
simplicity.  All  operating  system  activity  takes  place  in  a 
single  module.  The  main  disadvantage  is  the  excessive 
amount  of  time  external  interrupts  are  disabled.  In  order 
to  maintain  the  integrity  of  the  tables  it  maintains,  the 
monitor  disables  external  interrupts  whenever  it  is 
running.  Since  all  resource  managment  activity  takes  place 
within  the  monitor,  it  is  possible  that  interrupts  (e.g., 
information)  may  be  lost. 

The  kernel  approach  is  an  alternative  to  the 
monolithic  monitor  approach.  An  operating  system  based  on 
the  kernel  approach  is  composed  of  a  set  of  asynchronous 
processes  and  a  small  executive  module  (or  kernel). 

Resource  management  functions  are  placed  in  interruptable , 
asynchronous  processes.  The  kernel  provides  a  set  of 
primitive  operations  that  support  the  cooperation  of 
asychronous  processes.  Using  the  kernel  approach, 
interrupts  are  disabled  for  a  shorter  period  of  time.  In 
addition,  the  operating  system  is  easier  to  maintain  since 
data  structures  and  algorithms  are  encapsulated  in 
independent  processes.  In  an  effort  to  create  a  highly 
modular  and  understandable  system,  the  decision  was  made  to 
use  the  kernel  approach  to  structure  PCOS. 
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As  mentioned  in  the  preceding  discussion,  the  kernel 
must  provide  a  set  of  primitive  operations  that  support  the 
cooperation  of  asynchronous  processes.  After  reviewing  the 
literature  generated  by  past  operating  system  development 
efforts  (Agoston,  1977;  Bauer,  1975,  1976;  Bayer  & 

Lycklama,  1975;  Brinch-Hansen ,  1970,  1973;  Burgett  & 

O'Neil,  1977;  Crowley,  1981;  Faro,  Messina  &  Serra,  1981; 
Frank  &  Theaker,  1979;  Garetti,  Laface  &  Rivoira,  1981; 
Gorski,  1980;  Hammond,  1980;  Haridi  &  Thorelli,  1978;  Kahn, 
1978;  Lycklama  &  Bayer,  1978;  Madnick  &  Donovan,  1974; 

Mark,  Eggenberger  &  Nehmer,  1977;  Pohjanpalo,  1981;  Seidel 
&  Grebe,  1979;  Shaw,  Weiderman,  Andrews,  Felcyn,  Rieber  & 
Wong,  1975;  Sincoskie  &  Farber,  1980a,  1980b;  Solomon  & 
Finkel,  1979;  Thorelli,  1978),  it  was  decided  that  the 
kernel  should  provide  the  following  services: 

(1)  process  management, 

(2)  memory  management, 

(3)  interrupt  management, 

(4)  interprocess  communication  management,  and 

(5)  timer  management. 

Implementation 

System  Architecture 

PC0S  is  composed  of  several  hierarchical  layers 


called  levels.  The  levels  are  designed  to  be  highly 
independent  by  encapsulating  resources  and  data 
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representations  within  each  level.  Such  encapsulation  of 
objects  allows  levels  to  represent  abstract  views  of  the 
objects  for  which  they  are  responsible.  Figure  2-1  depicts 
the  different  layers  that  make  up  PCOS . 


+ - +  + - + 

!Executive!  !  User  ! 

Level  3  ! Process  !  !  Process  ! 

!  !  !  ! 

+ - +  + - + 

+ - + 

!  File  ! 

!  Server  ! 

|  i 

+ - + 

t  + - + 

!  !  I/O  ! 

!  !  Drivers  ! 

!  !  ! 

!  + - + 

?  i 


+ - + 

Level  0  !  Kernel  ! 

+ - + 


Figure  2-1.  PCOS  System  Hierarchy 


The  lowest  layer,  level  0,  is  the  system  kernel. 

The  kernel  is  the  nucleus  of  the  operating  system.  It 
provides  a  basic  set  of  services  which  are  available  to  all 
processes  in  the  system.  These  services  facilitate  process 
management,  memory  management,  interrupt  management, 
interprocess  communication  management,  timer  management, 
and  debugging. 

Level  1,  the  Basic  I/O  System  (BIOS),  is  composed  of 
a  set  of  processes  known  as  device  drivers.  These  device 
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drivers  are  responsible  for  providing  I/O  device  support. 
PCOS  currently  includes  a  console  driver,  a  disk  driver, 
and  a  printer  driver. 

The  Extended  I/O  System  (XIOS),  level  2,  currently 
includes  a  single  process,  the  File  Server.  The  File 
Server  presently  supports  only  sequential  file  access. 

The  highest  layer,  level  3,  is  composed  of  both  user 
and  system  processes.  Currently,  the  only  processes  which 
reside  at  level  3  are  the  Executive  Process  (EXEC)  and  the 
Command  Language  Interpreter  (CLI).  EXEC  is  responsible 
for  starting  the  system.  It  does  this  by  first  creating 
and  then  activating  the  other  processes  which  compose  PCOS. 
And,  the  CLI  is  the  process  responsible  for  providing  the 
user  interface  to  PCOS. 

Component  Details 

The  Kernel .  The  kernel  provides  a  set  of  basic 
services  which  can  be  used  by  any  process  in  the  system. 

The  kernel  primitives  or  services  can  be  grouped  into  six 
functional  categories:  process  management,  memory 
management,  interrupt  management,  interprocess 
communication  management,  timer  management,  and  debugging. 
Table  2-1  lists  the  services  provided  by  the  kernel.  And, 
Appendix  A  contains  descriptions  of  the  kernel  primitives. 

The  first  category  of  primitives  manipulate 


processes.  Processes  are  programs  that  perform  a  specific 
function.  A  process  consists  of  a  sequence  of 
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Table  2-1. 

Kernel  Services 

CATEGORY 

SERVICE 

Process  Management 

Create  Process 

Activate  Process 

Sleep 

Suspend  Process 

Destroy  Process 

Find  Process 

« 

Memory  Management 

Allocate  Memory 

Deallocate  Memory 

► 

w 

ft 

Interrupt  Management 

Connect  to  Interrupt 

Await  Interrupt 

Signal  Interrupt 

Disconnect  from  Interrupt 

«. 

jr 

Interprocess  Communication 
Management 

Send  Message 

Receive  Message 

Timer  Management 

Set  Clock 

Read  Clock 

Debugging 

System  Dump 

System  Trace 

instructions,  and  a  set  of  resources.  Processes  can  be 
categorized  as  either  user  or  system  processes.  A  user 
process  is  a  process  that  is  written  by  a  user.  It 
performs  a  function  directly  for  the  user.  A  system 
process  is  a  process  that  performs  functions  (or  services) 
for  a  user  process.  System  processes  are  supplied  with 
PCOS  that  provide  basic  device  management  services,  and 
extended  I/O  services. 


Processes  can  be  created  and  destroyed  dynamically. 
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The  maximum  number  of  processes  that  can  exist 
simultaneously  is  specified  at  system  generation.  The 
current  implementation  of  PCOS  can  handle  up  to  16 
concurrent  processes.  Each  process  within  PCOS  has  a 
unique  identification  number  (PID)  associated  with  it. 

Each  process  has  a  context  associated  with  it.  The 
context  of  a  process  is  the  information  that  specifies  the 
current  status  of  the  process.  The  current  values  of  the 
processor  registers,  including  the  instruction  pointer,  and 
the  resources  currently  allocated  to  it  define  the  context 
of  the  process. 

When  a  process'  execution  is  interrupted,  its 
context  is  saved  in  the  process  control  block  (PCB) 
associated  with  the  process  so  that  it  can  be  restarted  at 
a  later  time.  A  PCB  is  a  system  data  structure  which  is 
allocated  to  a  process  when  it  is  created.  A  PCB  has  two 
major  sections:  a  process  descriptor  block  (PDB);  and  an 
interrupt  save  area  (ISA).  Table  2-2  describes  the 
contents  of  a  PCB.  The  PDB  contains  information  including 
the  process  identification  number,  and  the  priority  of  the 
process.  The  ISA  provides  a  storage  area  for  the  process' 
registers  when  it  is  interrupted. 

During  its  existence,  a  process  goes  through  various 
process  states.  Figure  2-2  depicts  the  various  states  that 
a  process  may  go  through  during  its  existence. 


A  process  is  undefined  until  its  existence  is 


Table  2-2.  Process  Control  Block 


FIELD  NAME 

!  DESCRIPT [ON 

PROCESS  DESCRIPTOR  BLOCK: 

SUCCEED  I NG_PCB 

!  The  id  of  the  next  PCB  on  this  queue. 

!  This  field  is  used  to  link  PCBs  on  the 
!  ready  &  delay  queues. 

t 

PRECEEDING_PCB 

!  The  id  of  the  previous  PCB  on  this 
!  queue.  This  field  is  used  to  link 
!  PC3s  on  the  ready  &  delay  queues. 

t 

ID 

!  The  PID  associated  with  this  PCB. 

f 

NAME 

!  A  6  character  string  which  identifies 
!  the  process  which  this  PCB  represents. 

i 

PARENT 

!  The  PID  of  the  parent  process. 

! 

Y0UNGER_SI3 

!  The  PID  of  the  process  created  by  the 
!  parent  after  this  process. 

! 

OLDER_SH 

!  The  PID  of  the  process  created  by  the 
!  parent  before  this  process. 

f 

CHILDREN 

!  The  PID  of  the  last  process  created  by 
!  this  process. 

1 

PRIORITY 

!  The  priority  at  which  this  process 
!  executes . 

f 

STATUS 

!  The  current  status  of  this  process : 

!  running,  ready,  waiting,  suspended,  or 
!  undef ined  . 

| 

BLOCKS 

!  The  events  this  process  is  waiting  on: 

!  message,  interrupt,  and/or  timeout. 

!  This  field  is  only  meaningfull  if 
!  STATUS  is  waiting. 

i 

WAKEUPS 

!  The  events  that  have  happened  to  this 
!  process:  message,  interrupt,  and/or 
!  timeout. 

MESSAGE_COUNT 

!  The  number  of  messages  queued  for  this 
\  process . 

Table  2-2.  Process  Control  Block  (continued) 


FIELD  NAME 
MESSAGES 

DELAY 


NEXT  PCB 


PREV  PCB 


!  DESCRIPTION 

+ - 

!  A  pointer  to  the  first  IPCCB  (message) 

!  for  this  process. 

i 

!  A  word  which  specifies  the  time, 

!  in  system  time  units,  the  process 
!  is  to  be  delayed.  This  field  is 
!  only  meaningfull  if  STATUS  is  waiting 
!  and  BLOCKS  is  timeout. 

! 

!  The  id  of  the  next  PC3  on  either  the 
!  active  or  free  queue, 
t 

!  The  id  of  the  previous  PCB  on  either 
!  the  active  or  free  queue. 


INTERRUPT  SAVE  AREA 


AX 

!  AX 

i 

register 

save 

area . 

BX 

!  BX 

t 

register 

save 

area  . 

CX 

!  CX 

t 

register 

save 

area  . 

DX 

!  DX 

t 

register 

save 

ar ea  . 

SP 

!  SP 

i 

register 

save 

ar ea  . 

BP 

!  3P 
! 

register 

save 

area  . 

SI 

!  SI 
! 

register 

save 

ar  ea  . 

D I 

!  DI 

I 

register 

save 

area  . 

CS 

!  CS 
! 

register 

save 

area. 

DS 

!  DS 
! 

register 

save 

ar  ea  . 

SS 

!  SS 

i 

register 

save 

area  . 

ES 

!  ES 
! 

register 

sa '  e 

area. 

IP 

!  IP 

i 

register 

save 

area. 

FLAGS 

!  FLAGS  register  save  area 

recorded  in  a  PCB.  When  the  information  about  a  process 
has  been  entered  into  a  PCB,  the  process  moves  to  the 
suspended  state.  A  process  remains  in  the  suspended  state 
until  it  is  activated  by  another  process.  After  it  is 
activated,  a  process  moves  to  the  ready  state.  A  ready 
process  is  inserted  into  a  first-in,  first-out  priority 
queue  known  as  the  ready  list.  As  processes  complete 
execution,  the  process  dispatcher  removes  the  next  ready 
process  from  the  ready  list  and  assigns  the  processor  to 
it.  A  process  is  assigned  to  the  processor  by  restoring 
its  registers  from  its  ISA  and  then  transferring  control  to 
it.  A  process  remains  in  the  running  state  until  it  is 
interrupted,  waits  for  a  message,  is  suspended  by  another 
process,  or  completes  its  processing. 


+ - + 

!  undefined  ! 

+ - + 

i 

i 

+ - + 

!  suspended  ! 

+ - + 

! 

! 

+ - + 

!  ready  ! 

+ - + 

I 

i 

+ - + 

!  running  ! 

+ - + 


+ 


+ - + 

!  waiting  ! 

+ - + 


Figure  2-2. 


Process  State  Diagram 
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Six  primitives  are  provided  to  manage  processes: 
CREATE_PROCESS ,  ACTI VATE_PROCESS ,  SLEEP,  SUSPEND_PROCESS , 
DESTRO Y_PROCESS ,  and  FIND_PROCESS .  A  process  can  create  a 
descendant  process  (child)  using  the  CREATE_PROCESS 
primitive.  First,  a  PC3  is  removed  from  the  free  PCB  queue 
and  encoded  with  the  information  supplied  in  the  call. 

Then  the  new  PCB  is  queued  on  the  active  PCB  queue.  After 
creating  a  child  process,  the  parent  can  activate  it  using 
the  ACTIVATE_PROCESS  primitive,  suspend  it  using  the 
SUSPEND_PROCESS  primitive,  or  destroy  it  using  the 
DESTROY_PROCESS  primitive.  The  DESTRO Y_PROCESS  primitive 
also  destroys  all  descendents  of  the  destroyed  process.  A 
process  can  find  a  previously  created  process  using  the 
FIND_PROCESS  primitive. 

The  second  category  of  primitives  manipulate  memory. 
In  the  current  implementation  of  PCOS ,  a  fixed  amount  of 
menory  is  linked  onto  a  free  memory  queue.  Table  2-3 
describes  the  format  of  a  memory  control  block.  The  memory 


Table  2-3.  Memory  Control  Block 


+ - + - 

!  FIELD  NAME  !  DESCRIPTION 


NEXT 

SIZE 


A  pointer  to  the  next  MC3  in  the  free 
memory  queue. 


The  size, 
block. 


in  paragraphs,  of  this  memory 


+ 

! 

+ 


+  - 


-  +  - 


+ 


FILLER 


Forces  size  of  MCB  to  be  16  bytes  (  1 

paragraph ) . 


17 


r 


linked  on  the  free  memory  queue  is  used  to  satisfy  requests 
for  memory  from  processes. 

Two  primitives  are  provided  to  manage  memory: 
ALL0CATEJ1EM0RY,  and  DEALLOCATE _MEMOR Y .  The 
ALLOCATE_MEMORY  primitive  searches  the  free  memory  queue 
for  the  first  block  of  memory  that  satisfies  the  request. 

If  the  amount  of  memory  found  is  larger  than  the  amount  of 
memory  requested,  it  is  split  and  the  excess  returned  to 
the  free  memory  queue.  The  DEALLOCATE_MEMOR Y  primitive 
returns  the  specifed  block  of  memory  to  the  free  memory 
queue.  If  possible,  the  returned  block  is  combined  with 
adjacent  memory  blocks  on  queue  to  form  one  large  block 
of  free  memory. 

The  third  category  of  primitives  manipulate 
interrupts.  To  redirect  control  after  an  interrupt 
occurs,  the  Intel  80S3  microprocessor  uses  an  Interrupt 
Vector  Table  ( I V T ) .  The  I V T  starts  at  location  0  of 
main  memory  and  contains  256  interrupt  vectors  which  are 
numbered  0  -  255.  Each  interrupt  vector  can  be  loaded  with 
the  address  of  the  interrupt-service  routine  that  handles 
that  type  of  interrupt. 

In  order  to  manage  the  IVT,  the  kernel  maintains  an 
Interrupt  Vector  Status  Table  (I VST).  Table  2-4  describes 
the  contents  of  an  entry  in  the  I  VST.  There  is  one  entry 
in  the  I  VST  for  each  interrupt  vector  in  the  IVT. 

During  system  initialization,  interrupt  vectors 
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Table  2-4.  Interrupt  Vector  Status  Table  Entry 

+ - + - 

!  FIELD  NAME  !  DESCRIPTION 


The  status  of  this  interrupt:  allocated, 
or  unallocated  (e.g.  available). 

The  PID  of  the  interrupt  handler  process 
associated  with  this  interrupt. 


0  -  254  are  marked  as  available  for  use,  and  interrupt 
vector  255  is  marked  as  unavailable.  Interrupt  vector  255 
is  the  interrupt  vector  used  by  processes  to  access  the 
kernel . 

Four  primitives  are  provided  to  manage  interrupts: 
CONNECT_INTERRUPT,  AWAIT_INTERRUPT ,  SIGNAL_IMTERRUPT ,  and 
DISCON'NECT_INTERRUPT .  The  CONNECT_INTERRUPT  primitive 
reserves  an  interrupt  vector  for  a  process  and  assigns  an 
interrupt  handler  to  the  interrupt  vector.  The  process  can 
then  use  the  AWA IT_INTERRUPT  primitive  to  suspend  its 
execution  until  its  interrupt  handler  uses  the 
SIGNAL_INTERRUPT  primitive  to  activate  it  or  a  specified 
time  elapses.  The  DISCONNECT_INTERRUPT  primitive  cancels 
the  assignment  of  an  interrupt  vector  to  a  process. 

The  fourth  category  of  primitives  manipulate 
messages.  Processes  communicate  with  one  another  by 
exchanging  both  commands  and  data.  Processes  exchange  both 
commands  and  data  through  the  use  of  messages. 

Messages  are  the  basic  unit  of  information  exchange 
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between  processes.  The  interprocess  communication  (IPC) 
facility  of  PCOS  provides  a  flexible  communication 
mechanism  which  can  be  used  to  support  communication 
between  processes,  general  network  communication,  and 
resource  sharing.  The  interprocess  communication  facility 
provided  by  PCOS  is  a  pure  datagram  facility.  It  neither 
guarantees  delivery  of  a  message  nor  acknowledges  its 
receipt . 

A  message  is  delivered  using  an  interprocess 
communication  control  block  (IPCCB).  A  IPCCB  consists  of 
two  parts:  (1)  a  header;  and  (2)  a  body.  The  format  of  a 
IPCCB  is  illustrated  in  Table  2-5.  The  message  header 
contains  information  which  identifies  the  the  process 
sending  the  message,  and  the  length  of  the  body  of  the 
i.,essage.  The  body  of  the  message  contains  the  information 
being  exchanged. 

Table  2-5.  Interprocess  Communication  Control  Block 

+ - +  — - 

!  FIELD  NAME  !  DESCRIPTION 
+ - + - 


NEXT 

r 

? 

i 

A  pointer  to  the  next  IPCC3  in  this 
process’  message  queue. 

SOURCE 

i 

! 

1 

The  PID  of  the  process  which  sent  this 
message . 

LENGTH 

1 

f 

The  length,  in  bytes,  of  this  message. 

DATA 

i 

- +  . 

The  message . 

Two  primitives  are  provided  to  manage  messages 
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SENDJ1ESSAGE,  and  RECEIVE_MESSAGE .  The  SEND_MESSAGE 
primitive  sends  the  message  specified  to  the  designated 
process.  After  the  kernel  allocates  memory  for  an  IPCCB 
for  the  message,  the  message  along  with  its  length  and  the 
PID  of  the  sending  process  is  copied  into  the  IPCCB.  The 
IPCCB  is  then  linked  to  the  FIFO  message  queue  of  the 
destination  process.  If  the  destination  process  is 
awaiting  a  message  and  executes  at  a  higher  priority  than 
the  sending  process,  it  receives  control  of  the  CPU  and  the 
sending  process  is  inserted  into  the  ready  list.  If  the 
destination  process  is  awaiting  a  message  and  executes  at 
a  priority  equal  to  or  lower  than  the  sending  process,  it 
i  is  inserted  into  the  ready  list  and  the  sending  process 

continues  execution.  And,  if  the  destination  process  is 
not  awaiting  a  message,  the  sending  process  simply 
continues  execution. 

The  RECEIVE_MESS AGE  primitive  returns  the  message 
at  the  head  of  the  process'  FIFO  message  queue.  The 
message  is  first  copied  into  the  process'  data  space, 
then  dequeued  from  the  message  queue,  and  finally  the 
memory  used  to  buffer  the  message  is  returned  to  the 
system.  If  no  messages  are  queued  and  no  delay  is 
specified,  control  returns  to  the  receiving  process; 
however,  if  a  delay  is  specifed,  the  process  doesn't 
receive  control  until  it  receives  a  message  or  the  delay 
has  elapsed.  And,  if  an  infinite  delay  is  specified,  the 
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process  doesn't  resume  execution  until  it  receives  a 


message . 

The  fifth  category  of  primitives  manipulate  the 
system  clock.  The  system  clock  is  initialized  to  00:00:00 
hours  0  ticks  during  system  initialization.  A  system  time 
unit  or  tick  is  l/20th  of  a  second  in  duration. 

Two  primitives  are  provided  to  manage  the  system 
clock:  SET_CL0CK  and  READ_CL0CK.  The  SET_CL0CK  primitive 

sets  the  system  clock  to  the  value  specified;  while  the 
READ_CL0CK  primitive  returns  the  current  setting  of  the 
system  clock. 

And,  the  sixth  category  of  primitives  facilitate 
debugging.  The  primitives  which  facilitate  debugging  are 
SYSTEM_DUMP  and  SYSTEM_TRACE .  The  SYSTEMJJUMP  primitive 
produces  a  hexadecimal  dump  of  the  contents  of  the 
registers  and  the  specified  memory  block  at  the  time  of 
the  dump  on  the  system  printer.  The  SYSTEM_TRACE  primitive 
prints  the  message  specified  on  the  system  printer. 

The  Basic  1/0  System.  The  Basic  1/0  System  (BIOS) 
of  PC0S  is  responsible  for  device  management.  Three  device 
drivers  are  included  in  the  BIOS  of  PC0S :  a  console 
driver,  a  disk  driver,  and  a  printer  driver.  The  services 
provided  by  each  of  the  driver  processes  are  listed  in 
Table  2-6 . 

Communication  with  the  device  driver  processes  that 
form  the  BIOS  of  PC0S  is  achieved  through  the  use  of 
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Table  2-6.  Device  Driver  Services 


■* 

t 

t 


DEVICE  DRIVER 

SERVICE 

Console 

Read  a  Character  from  Keyboard 

Write  a  Character  to  Video  Monitor 

Disk 

Read  a  Sector 

Write  a  Sector 

Reset  Diskette  System 

Verify  Sector 

Format  Disk 

Printer 

Write  Character  to  Printer 

Reset  Printer 

Read  Printer  Status 

messages.  Basically,  each  device  driver  is  a  server 
process  that  is  responsible  for  a  specific  system  resource. 
Each  server  process  was  developed  using  the  Requestor- 
Server  Model  (Britton  &  Stickel,  1980)  as  a  guide.  Figure 
2-3  illustrates  the  basic  form  of  a  server  process. 


procedure  terminal; 
begin 
loop 

r  e  c  e i v  e_a_m  e  s  s  a  g  e ; 
case  message . type  of 

when  0  =>  read_character ; 
when  1  =>  display_character ; 
end  case  ; 
send_a_repl y ; 
end  loop; 
end  terminal; 


Figure  2-3.  Example  Server  Process 


Each  server  process  (e.g., 


console  device  driver) 
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waits  for  a  service  request  using  the  RECEIVE_MESSAGE 
primitive.  Once  it  has  processed  a  service  request,  it 
sends  a  reply  message  to  the  requestor  using  the 
SEND_MESSAGE  primitive.  This  sequence  of  operations 
continues  until  the  server  is  terminated. 

The  Extended  I/O  System.  The  Extended  I/O  System 
(XIOS)  sequential  disk  file  access.  The  File  Server  is  the 
only  component  of  the  XIOS.  Table  2-7  lists  the  services 
that  are  provided  by  the  File  Server. 

Table  2-7.  File  Server  Services 

CATEGORY  SERVICE 

File  System  Volume  Mount  a  File  System  Volume 

Dismount  a  File  System  Volume 

File  Connection  Open  File 

Close  File 

File  I/O  Read  a  Character  from  a  File 


Like  the  device  diivers  that  form  the  BIOS  of  PCOS, 
the  file  server  is  also  a  server  process.  Other  processes 
can  communicate  with  the  file  server  through  the  use  of 
messages  . 

To  open  a  file,  a  task  sends  an  OPEN  message  which 
conatins  the  name  of  the  file  to  be  opened  to  the  file 
server.  The  task  then  blocks  itself  by  waiting  for  the 
file  server's  reply.  When  the  file  server  receives  the 
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message,  it  interprets  it,  opens  the  file  (if  it  exists), 
and  assigns  a  unique  file  id  to  it.  The  file  server  then 
sends  a  completion  message  which  contains  the  file  id  to 
the  process.  This  causes  the  process  to  be  rescheduled. 
Using  the  file  id  assigned  by  the  file  server,  the  process 
can  now  perform  I/O  operations  on  the  file. 

The  Command  Language  Interpreter.  The  system 
operator  or  user  interacts  with  PCOS  through  the  command 
language  interpreter  (CLI).  The  user  issues  commands  to 
the  system  through  a  command  language  which  is  interpreted 
by  the  CLI. 


Table  2-8.  CLI  Commands 


COMMAND 

DESCRIPTION 

DISMOUNT 

Mounts  a  file  system  volume  on  disk 
drive  0 . 

DISPLAY 

Displays  the  contents  of  a  file  in 
hexadecimal  on  either  the  system 
console  or  the  printer. 

MOUNT 

Dismounts  a  file  system  volume  from 
disk  drive  0. 

PRINT 

Prints  the  contents  of  a  file  on  the 
printer  . 

TIME 

Displays  the  current  time. 

TYPE 

Displays  the  contents  of  a  file  on  the 
system  console . 

*  l" 


The  CLI  prompts  the  user  for  a  command  line  by 
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writing  '$  '  to  the  system  console.  A  command  line 
consists  of  a  command  name  terminated  by  a  carriage  return. 
Table  2-8  lists  the  commands  which  are  provided  by  the  CLI. 
Once  the  user  enters  a  command  line,  the  CLI  checks  to  see 
if  the  command  is  valid.  If  it  is,  the  command  is  then 
executed;  if  it  isn't,  the  CLI  displays  an  error  message 
and  then  prompts  the  user  for  another  command  line.  The 
user  is  prompted  for  any  arguments  that  a  command  needs 
to  perform  its  function. 

When  a  command  has  completed  execution,  the  CLI 
prompts  the  user  for  another  command  line. 

The  Executive  Process.  The  initialization  or 
startup  of  both  system  and  user  processes  is  accomplished 
by  the  Executive  Process  (EXEC).  After  all  system  data 
structures  have  been  initialized  by  the  kernel 
initialization  routine,  control  is  passed  to  EXEC.  EXEC 
then  creates  and  activates  the  other  processes  that  make  up 
PCOS  using  the  CR EATE_PROCESS  and  ACTI V ATE_PROCESS  kernel 
primitives.  Once  it  has  started  the  other  system 
processes,  EXEC  suspends  execution  awaiting  a  system 
termination  message. 
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CHAPTER  III 

FURTHER  RESEARCH  AND  DEVELOPMENT 

The  need  for  the  following  modifications  to  the  PCOS 
kernel  was  made  apparent  during  the  development  of  the  BIOS 
device  driver  processes. 

The  current  implementation  of  the  PCOS  kernel  does 
not  include  primitive  operations  for  exception  management. 
An  exception  occurs  whenever  a  kernel  primitive  fails. 

Each  kernel  primitive  returns  a  condition  code  that 
indicates  the  success  or  failure  of  an  operation. 

Currently,  processes  must  check  the  condition  code  after 
each  kernel  call  in  order  to  determine  if  an  exception 
occurred.  In  order  to  reduce  the  amount  of  checking  a 
process  must  perform,  the  kernel  should  be  modified  to 
include  exception  management  primitives. 


Table  3-1.  Proposed  Exeception  Management  Services 


CATEGORY 

SERVICE 

Exception  Management 

Create 

Exception 

Handler 

Destroy 

Exception 

Handler 

Processes  should 

be  able  to  specify 

an  exception 

handler  that  is  to  receive  control  whenever  an  exception 


occurs.  Table  3-1  lists  the  exception  management  services 
that  the  kernel  should  provide. 

Another  operation  which  the  PCOS  kernel  does  not 
currently  support  is  the  selective  receipt  of  messages. 

This  seems  to  be  the  greatest  deficiency  of  the  PCOS 
kernel.  Consider  the  following  scenario.  Process  A  sends 
a  message  requesting  some  service  to  Process  B,  and  then 
continues  processing.  In  order  to  fulfill  the  request. 
Process  B  sends  a  request  message  to  Process  C  and  then 
waits  for  a  response  message  from  Process  C.  Before 
Process  C  can  respond,  Process  A  issues  another  request 
message  to  Process  B.  Since  Process  B  is  waiting  for  a 
message,  it  is  awakened  and  given  the  second  request 
message  from  Process  A.  However,  Process  B  is  expecting  a 
response  message  from  Process  C,  not  a  request  message  from 
Process  A. 

There  are  two  possible  solutions  to  this  problem. 

The  first  solution  is  to  require  processes  internally  queue 
messages  that  they  are  not  ready  to  process.  The  second 
solution  is  to  modify  the  kernel  to  include  a  selective 
message  receipt  primitive.  The  second  solution  is 
recommended  since  it  simplifies  the  construction  of  server 
processes. 

This  solution  can  be  implemented  by  modifying  the 
r ece i ve_message  primitive  to  only  receive  a  message  from  a 
specified  process,  and  by  adding  a  recei  ve_an_v_message 
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primitive  that  receives  a  message  from  any  process. 

Once  the  above  modifications  are  made,  the  kernel 
will  be  suitable  for  continued  development  of  PCOS . 


29 


CHAPTER  IV 

CONCLUSION 

This  thesis  documents  the  design  and  implementation 
of  an  operating  system  for  the  IBM  PC.  The  purpose  of  this 
research  project  was  to  develop  an  operating  system  which 
could  be  used  to  provide  students  with  a  better 
understanding  of  operating  system  principles. 

After  discussing  the  motivation  for  the  PCOS 
project,  the  development  of  PCOS  was  discussed.  First,  the 
requirements  for  PCOS  were  discussed.  The  requirements  for 
PCOS  were  established  after  reviewing  the  capabilities 
offered  by  several  commercially  available  operating 
systems. 

Next,  the  design  criteria  and  the  overall  design  of 
PCOS  was  discussed.  The  design  of  PCOS  is  based  on  the 
kernel  approach.  New  user  requirements  such  as  the  need  to 
support  a  new  I/O  device  can  be  easily  supported  through 
the  addition  of  new  processes.  In  retrospect,  we  believe 
the  kernel-based  design  of  PCOS  provides  a  good  base  for 
further  research. 

Then,  the  implementation  of  PCOS  was  discussed. 

PCOS  was  designed  and  implemented  on  an  IBM  PC.  Because  of 
the  work  needed  to  construct  a  complete  operating  system, 
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this  project  focused  on  the  design  and  implementation  of 
the  kernel  and  the  low-level  device  drivers.  The  kernel 
provides  a  set  of  primitive  operations  that  support 
cooperation  of  asynchronous  processes.  And,  the  device 
drivers  provide  support  for  a  video  display,  keyboard, 
disk  drive,  and  printer.  A  simplistic  file  server  and 
command  language  interpreter  were  also  developed. 

Modifications  and  extensions  to  PCOS  were  then 
presented.  The  modifications  presented  are  necessary  in 
order  to  refine  the  current  implementation  of  PCOS  on 
the  IBM  PC.  The  full  implementation  of  the  File  Server, 
and  the  Command  language  Interpreter  has  been  left  for 
future  research  efforts. 

The  author  feels  that  PCOS  is  a  valuable  pedagogical 
aid.  Although  PCOS  is  not  nearly  as  complex  as  OS/MVS  or 
Unix,  it  does  contain  many  of  the  basic  concepts  found  in 
commercially  available  operating  systems.  Due  to  its  more 
simplistic  nature,  a  detailed  description  is  easier  to 
provide  and  thus  easier  for  students  to  understand. 

This  research  project  incorporated  the  use  of 
various  techniques  in  several  topic  areas  and  resulted  in  a 
challenging  and  rewarding  experience  for  the  author.  The 
author  hopes  that  this  project  will  generate  continued 
interest  in  the  subject  of  operating  system  design. 
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ACTIVATE_PROCESS 

FORMAT: 

status  :=  act ivate_process( process) ; 

INPUT  PARAMETERS: 

process  A  word  containing  the  id  of  the  process 

to  be  activated. 

OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  ACTIVATE_PROCESS  primitive  activates  a  process  if  it 
is  suspended. 

CONDITION  CODE: 

C C_0 K  No  exceptional  conditions. 

CC_EXIST  The  specified  process  does  not  exist. 

CC_ACTIVE  The  specified  process  is  already 

active. 


ALLOCATE  MEMORY 


FORMAT: 

status  :=  allocate_memory ( amount , 

memory )  ; 


INPUT  PARAMETERS: 

amount  A  word  that  specifies  the  number  of 

paragraphs  (a  paragraph  is  16  bytes) 
requested . 

OUTPUT  PARAMETERS: 

memory  A  pointer  in  which  PCOS  will  return  the 

address  of  the  first  available  byte  of 
the  allocated  memory  block. 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  ALLOCATE_MEMOR Y  primitive  returns  a  pointer  to  the 

first  available  byte  of  the  requested  memory  block. 


CONDITION  CODES: 

CC_0K  No  exceptional  conditions. 

CC_MEMORY  There  is  not  enough  memory  available  to 

satisfy  the  request. 
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AWAIT_INTERRUPT 

FORMAT: 

status  await_interrupt(delay ) ; 

INPUT  PARAMETERS: 

delay  A  word  which  specifies  the  amount  of 

time  the  process  is  willing  to  wait  for 
an  interrupt.  If  zero,  the  process  is 
willing  to  wait  indefinitely.  If 
positive,  delay  indicates  the  number  of 
system  time  units  the  process  is 
willing  to  wait.  There  are  20  system 
time  units  per  second. 

OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  AWAIT_INTERRUPT  primitive  causes  the  currently 
executing  process  to  be  suspended  until  the  interrupt 
with  which  it  is  associated  occurs  or  the  delay  is 
exhausted. 


CONDITION  CODES: 

CC_0K  No  exceptional  conditions. 


CC  TIMEOUT 


A  timeout  occurred. 
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CONNECT  INTERRUPT 


FORMAT: 

status  :=  connect_interrupt ( interrupt , 

handler  )  ; 


INPUT  PARAMETERS: 

interrupt  A  word  indicating  the  interrupt  vector 

with  which  the  process  is  to  be 
associated . 

handler  A  pointer  to  the  first  instruction  of 

the  interrupt  handler. 


OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 


DESCRIPTION: 

The  CONNECT_INTERRUPT  primitive  assigns  a  process  and 
an  interrupt  handler  to  an  interrupt  vector. 


CONDITION  CODES: 

CC_0K  No  exceptional  conditions. 

CC_EXIST  The  specified  interrupt  vector  does  not 

exist. 

CC_ASSIGN  The  specified  interrupt  vector  is 

already  assigned  an  interrupt  handler. 
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CREATE  PROCESS 


FORMAT: 

status  :=  create_process ( process , 

name , 
priority  , 
star t_addr ess , 
s  t  a  c  k_a  d  d  r  e  s  s , 
stack  size  ) ; 


INPUT  PARAMETERS: 

name  A  field  which  contains  a  string  of  six 

ASCII  characters  giving  the  name  of  the 
process , 

priority  A  word  that  specifies  the  priority  of 

the  new  process. 

star t_address  A  pointer  to  the  first  instructions  of 

the  new  process. 

s tack_add ress  A  pointer  to  the  base  of  the  new 

process'  stack. 

stack_size  A  word  containing  the  size,  in  bytes, 

of  the  new  process'  stack. 

OUTPUT  PARAMETERS: 

process  A  word  in  which  PCOS  will  return  the 

identification  number  for  the  new 
process  . 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  CREATE_PROCESS  primitive  creates  a  process  and 

returns  an  id  for  it. 

CONDITION  CODES: 


CC  OK 


No  exceptional  conditions. 
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CC_LIMIT  The  new  process  would  except  the 

maximum  number  of  process  allowed  by 
thesystem. 


DEALLOCATE  MEMORY 


FORMAT: 

status  :=  deallocate_raemory( memory ) ; 

INPUT  PARAMETERS: 

memory  A  pointer  to  the  first  byte  of  the 

memory  block  to  be  retruned  to  the 
system . 

OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  RELEASE_MEMORY  primitive  returns  a  block  of  memory  to 

the  system. 

CONDITION  CODES: 

CC  OK 


CC  EXIST 


No  exceptional  conditions. 

The  value  contained  in  memory  does  not 
point  to  a  valid  memory  block. 


DESTROY  PROCESS 


FORMAT: 

status  :=  dest roy_process ( process  )  ; 


INPUT  PARAMETERS: 

process  A  word  containing  the  id  of  the  process 

to  be  destroyed. 


OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 


DESCRIPTION: 

The  DESTROY_PROCESS  primitive  deletes  the  specified 
process  from  the  system.  The  process  must  be  suspended 
before  it  can  be  destroyed. 


CONDITION  CODES: 
CC_OK 
CC_EXIST 
CC  STATE 


No  exceptional  conditions. 

The  specified  process  does  not  exist. 
The  specified  process  is  not  suspended. 
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DISCONNECT  INTERRUPT 


FORMAT: 

status  :=  disconnect_interrupt ( interrupt )  ; 

INPUT  PARAMETERS: 

interrupt  A  word  specifying  the  interrupt  vector 

from  which  the  process  is  to  be 
disconnected  . 


OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  DISCONNECT__INTERRUPT  primitive  cancels  the  assignment 
of  the  process  to  an  interrupt  vector. 

CONDITION  CODES: 

CC_0K  No  exceptional  conditions. 

CC_EXIST  The  specified  interrupt  vector  does  not 

exit. 

The  specified  interrupt  vector  is  not 
currently  assigned  an  interrupt 
handler,  or  is  not  assigned  to  the 
process  . 


CC  ASSIGN 
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FIND  PROCESS 


FORMAT: 

status  :=  f ind_p roc e s s ( pr oc es s , 

name  )  ; 

INPUT  PARAMETERS: 

name  A  field  which  contains  a  string  of  six 

ASCII  characters  giving  the  name  of  the 
process  . 

OUTPUT  PARAMETERS: 

process  A  word  in  which  PCOS  will  return  the  id 

of  the  process  whose  name  is  identical 
to  the  identifier  contained  in  name. 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  FIND_PROCESS  primitive  searches  the  queue  of  process 
known  to  PCOS.  If  a  process  is  found  whose  name  is 
identical  to  the  process  name  contained  in  name  its  id  is 
returned  in  process.  Otherwise,  an  C C_E XIST  exceptional 
condtion  occurs. 


CONDITION  CODES: 
CC  OK 


CC  EXIST 


No  exceptional  conditions. 

The  specified  process  does  not  exist. 


READ  CLOCK 


FORMAT: 

status  :=  read_clock( hours , 

minutes , 
seconds , 
ticks )  ; 

INPUT  PARAMETERS: 
none 

OUTPUT  PARAMETERS: 


hours 

A 

word 

containing 

the 

present 

hour . 

minutes 

A 

word 

containing 

the 

present 

minute . 

seconds 

A 

word 

containing 

the 

present 

second  . 

ticks 

A 

word 

containing 

the 

present 

tick . 

status 

A 

word 

which  contains 

the  condition 

code  generated  by 

this 

primitive . 

DESCRIPTION: 

The  READ_CLOCK  primitive  returns  the  current  setting  of 
the  system  clock. 

CONDITION  CODES: 

CC_OK  No  exceptional  conditions. 
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RECEIVE  MESSAGE 


FORMAT: 

status  :=  receiv e_m essage(source, 

message , 
size , 
delay  ) ; 

INPUT  PARAMETERS: 

message  A  message  buffer. 

size  A  word  containing  the  size  of  the 

message  buffer. 

delay  A  word  which  specifies  the  amount  of 

time  the  process  is  willing  to  wait  for 
a  message. 

OUTPUT  PARAMETERS: 

source  A  word  containing  the  process  id  of  the 

process  that  sent  the  message. 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  RECEIVE_MESS AGE  primitive  returns  a  message  to  the 

calling  process. 

CONDITION  CODES: 

CC_0K  No  exceptional  conditions. 

CC_TIMEOUT  A  message  was  not  received  before  the 

delay  was  exhausted. 


SEND  MESSAGE 


FORMAT: 

status  :=  send__message( destination  , 

message, 
size  )  ; 

INPUT  PARAMETERS: 

destination  A  word  containing  the  id  of  the  process  to 

which  the  message  is  to  be  sent. 

message  A  message  buffer. 

size  A  word  containing  the  size  of  the 

message  buffer. 

OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  SEND_MESSAGE  primitive  sends  a  message  to  the 
specified  process. 

CONDITION  CODES: 

CC  OK 


CC  EXIST 


No  exceptional  conditions. 

The  specified  process  does  not  exist. 
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SET_CLOCK 

FORMAT: 

status  :=  se t_c lock ( hour s  , 

minutes  , 
seconds , 
ticks )  ; 

INPUT  PARAMETERS: 

hours  A  word  containing  the  new  hour  value, 

minutes  A  word  containing  the  new  minute  value, 

seconds  A  word  containing  the  new  second  value, 

ticks  A  word  containing  the  new  tick  value. 

OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  SET_CLOCK  primitive  sets  the  sytem  clock. 

CONDITION  CODES: 


CC  OK 


No  exceptional  conditions. 
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SIGNAL_INTERRUPT 

FORMAT: 

status  :=  signal_interrupt ( interrupt )  ; 

INPUT  PARAMETERS: 

interrupt  A  word  indicating  the  interrupt  vector 

whose  process  isto  be  signaled. 

OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  SIGNAL_INTERRUPT  primitive  allows  an  interrupt 

handler  to  activate  its  associated  interrupt  process 

CONDITION  CODES: 

CC_0K  No  exceptional  conditions. 

CC_EXIST  The  specified  interrupt  vector  does  not 

exist. 

CC_ASSIGN  The  specified  interrupt  vector  is  not 

assigned  an  interrupt  process. 
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SLEEP 

FORMAT: 

status  :=  sleep ( delay  )  ; 


INPUT  PARAMETERS: 

delay  A  word  which  specifies  the  number  of 

system  time  units  the  process  wishes  to 
be  asleep.  There  are  20  system 
time  units  per  second. 

OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 


DESCRIPTION: 

The  SLEEP  primitive  causes  the  currently  executing  process 
to  suspend  its  execution  for  a  specified  amount  of  time. 


CONDITION  CODES: 


CC  OK 


No  exceptional  conditions. 
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SUSPEND_PROCESS 

FORMAT: 

status  :=  suspend_process(process)  ; 


INPUT  PARAMETERS: 

process  A  word  containing  the  id  of  the  process 

to  be  suspended. 

OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 


DESCRIPTION: 

The  SUSPEND_PROCESS  primitive  suspends  a  process. 
CONDITION  CODES: 

CC_OK  No  exceptional  conditions. 


CC  EXIST 


The  process  indicated  could  not  be 
found  . 
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SYSTEM  DUMP 


FORMAT: 

status  :=  system_dump( star t_address  , 

stop_address  ) ; 

INPUT  PARAMETERS: 

star f_address  A  pointer  containing  the  address  of  the 

first  byte  to  be  displayed. 

stop_address  A  pointer  containing  the  address  of  the 

last  byte  to  be  displayed. 

OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  SYSTEM_DUMP  primitive  produces  a  snapshot  of  the 

contents  of  the  registers  and  the  specified  memory  block. 

The  dump  is  displayed  on  the  system  printer. 


CONDITION  CODES: 
CC  OK 


No  exceptional  conditions. 
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SYSTEM_TRACE 

FORMAT: 

status  :=  system_t  race (message  ) ; 

INPUT  PARAMETERS: 

message  A  character  string. 

OUTPUT  PARAMETERS: 

status  A  word  which  contains  the  condition 

code  generated  by  this  primitive. 

DESCRIPTION: 

The  SYSTEM_TRACE  primitive  displays  the  specified 
message  on  the  system  printer. 

CONDITION  CODES: 

CC_OK  No  exceptional  conditions. 
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